오늘 한 일

• Android 앱개발

---

Android 데이터베이스 연결

데이터베이스에서 Pk가 가지는 기본적인 의미?

데이터를 저장하는 것? 데이터의 자료구조 = 데이터 저장 및 조회의 성능을 고려해야한다

저장 → 저장속도.. 복잡하지 않은 구조, 고려할 필요없음
저장 → 저장공간.. SQL을 이용하므로 데이터 중복 최소화
조회 → SQL 관계성과 Pk를 이용한 데이터 접근

데이터

• Pill 정보 ..1
  = 시간대(설계), 이름, 사진 등등

• 시간별 Done 정보 ..2 = 시간대(인스턴스), Done

• 시간-Pill별 Done 정보 ..3 = 시간대(인스턴스), 이름, Done

→ 대부분 시간대를 포함한다
→ 시간대 설계용과 인스턴스용이 있다 ⇒ 설계용으로 처리?

조회상황

• 3 체크 패널 불러오기 = 해당 시간에 해당하는 PillDone 리스트업
• 2 체크(캘린더) 패널 불러오기
• 1 약 정보들 불러오기 = 저장되어있는 약의 정보들
• 1 약 정보 1개 불러오기

저장상황

• 시간대 갱신 → 자동 2,3 생성, 삭제
• 약 Done 갱신 → 자동 2,3 변경
• 1 약 생성, 삭제, 업데이트

결론: 설계

TRY: 시간대 인스턴스용 생성을 위해 설계용을 따로 정의하기

아침/점심/저녁/자기전(0,1,2,3 으로 구별)
| 약(간략화)
| 2(Date)

1(약)
|_ 다양한 정보들

3(Date - Pill)

→ 자동 2,3 생성에 용이
: 아침 → 약 간략화 받아옴 → 약 간략화 모두 생성

→ 자동 2,3 삭제에 용이하지 않음
: (삭제를 한다면) 날짜단위로 삭제할 것이기 때문에.. 3번의 Date 일일이 확인 후 삭제

→ 약 생성, 삭제, 업데이트에 적당히 용이(2번 Pill Done 관리자에서 다루며 Done과 추상화시킴)
: 1번 생성 & 2번에 여러 개 생성 && 약 삭제해도 3에서 간략정보로 이전 내용 조회에 이상없음

→ 3 조회 빠름 = 한 큐에
→ 2 조회 느린편 아침 → 2
→ 1 조회 빠름 = 한 큐에

결론: 결과

• 메인 체크 패널 불러올 때 = 조회효율적
  : dtid → datetime → All pill_checked

• 날짜별 체크 패널 불러올 때 = 조회효율적
  : dtids → All datetime’s checked

• 약 정보들 패널에 불러올 때 =조회효율적 : → All pill

• 약 정보 1개 불러올 때 = 조회효율적 : 위에서 불러온 코드에서 바로 실행

• 시간변경시 체크 패널 생성할 때 = 효율은 모르겠지만 매커니즘 이해하기 쉬움 : d(tid) → time → All pill_light에서 pid&name 확인 ⇒ dtid + datetime 생성 → dtid → pid&names + pill_checks 생성
• 시간 지났을 때 체크 패널 삭제할 때 = 저장효율적인편 : (d)tids → 모두 삭제
• 약 먹었다고 체크할 때 = 저장비효율적 : dtid → datetime → pid → pill_check checked 변경 & 추가로 조건 확인 후 datetime checked 변경가능

• 약 생성할 때 = 저장비효율적 : pill 생성 → tids&pid → pill_light 생성
• 약 변경할 때 = 저장비효율적 : pid → pill 변경 : tids → All times → pid → pill_light 삭제 : tids&pid → times → pid → pill_light 생성
• 약 삭제할 때 = 저장비효율적 : pid → pill 삭제 : tids → All times → pid → pill_light 삭제

⇒ 저장 비효율 but, 사용자 경험에 큰 문제는 없다고 생각 ⇒ 약 생성 후 약이 등록될 때 까지 대기하는 상황을 쉽게 상상해볼 수 있음